The advent of cloud-based computing architectures has opened new possibilities for the rapid and scalable deployment of virtual Web stores, media outlets, social networking sites, and many other on-line sites or services. In general, a cloud-based architecture deploys a set of hosted resources such as processors, operating systems, software and other components that can be combined together to form virtual machines. A user or customer can request the instantiation of a virtual machine or set of machines from those resources from a central server or cloud management system to perform intended tasks, services, or applications. For example, a user may wish to set up and instantiate a virtual server from the cloud to create a storefront to market products or services on a temporary basis, for instance, to sell tickets to or merchandise for an upcoming sports or musical performance. The user can subscribe to the set of resources needed to build and run the set of instantiated virtual machines on a comparatively short-term basis, such as hours or days, for their intended application.
Typically, when a user utilizes a cloud, the user must track the software applications executed in the cloud and/or processes instantiated in the cloud. For example, the user must track the cloud processes to ensure that the correct cloud processes have been instantiated, that the cloud processes are functioning properly and/or efficiently, that the cloud is providing sufficient resources to the cloud processes, and so forth. Due in part to the user's requirements and overall usage of the cloud, the user may have many applications and/or processes instantiated in a cloud at any given instant, and the user's deployment of virtual machines, software, and other resources can change dynamically over time. In cases, the user may also utilize multiple independent host clouds to support the user's cloud deployment. That user may further instantiate and use multiple applications or other software or services inside or across multiple of those cloud boundaries, and those resources may be used or consumed by multiple or differing end-user groups in those different cloud networks.
In terms of the administrative capture of a user's resource consumption that may be spread across several independent host clouds, existing platforms today provide no mechanism by which a resource provider and/or other operator or administrator can track the resource consumption by the user across all currently utilized host clouds, in an organized or centralized fashion. That is, the user may have instantiated a certain number of instances or copies of an operating system or application in one host cloud, while at the same time running or executing another number of instances of the same operating system or application in another, independent host cloud or clouds. In instances, the set of host clouds may operate independently and with no operating agreement between them. Usage data for the user may therefore not be shared or be visible between those host clouds. In addition, the set of host clouds can also change over time during the course of a week, month, and/or other period, making coordination of subscription details including usage history difficult or impossible.
In cases where the user may subscribe to operating system, application, and/or other software or hardware resources based on subscription levels or limits, it may accordingly be difficult or impossible to keep a running tally of the user's resource consumption on an aggregate basis, across all operative host clouds. If the user, for instance, has a subscription limit of 300 instances of an executing application with a per-cloud limit of 100 instances, and reaches 100 instances in one host cloud at the same time that 90 instances of that application is operating in a second host cloud and 120 are operating in a third cloud, the application provider, individual host clouds, and/or other entities may not be able to timely or accurately determine that the user has reached their instance limit in one cloud, and exceeded their instance threshold in a second cloud. This can occur, for example, because individual host clouds may not have visibility on the resource consumption and/or subscription limits or parameters that may apply in other clouds.
Moreover, those entities and their associated billing infrastructure may not be equipped to identify not just over-consumption of resources within certain subscription or usage periods, but also under-consumption of those resources. The individual host clouds and other entities may therefore not be able to accurately apply the user's subscription limits and/or other parameters, such as supplemental billing for over-limit resource consumption, on an aggregate basis. Among other things, this may prevent any individual host cloud, or application provider or other resource provider, from identifying the potential under-consumption of one or more subscribed resources in diverse host clouds that could, in theory, be captured and aggregated to permit the user to receive a credit, offset, and/or other adjustment to their overall subscription costs, on an aggregate basis.
Further, in terms of subscription management and associated tracking of resource consumption, in known cloud management systems and related billing infrastructure, the subscription period or other time interval that is used to track the user's consumption of processor, memory, operating system, or other resources may be fixed or predetermined. That interval may be set, for example, to a one-hour, one-day, and/or other period or interval over which the user's consumption of cloud resources is accumulated. When a conventional cloud management system employs such fixed or relatively coarse-grained set of intervals, however, the resource usage that is captured may not be fully accurate or timely. When the cloud management system or associated logic takes a snapshot of operating system instances, for instance, on a once-per-hour basis, if a particular user exhibits bursty or other transient consumption patterns, such as consumption of operating system instances that exceeds subscription limits for only a few minutes at a time, the tracking infrastructure may not be able to detect or resolve those peaks. In cases, the user's subscription levels might call out for additional subscription fees, limit adjustments, and/or other factors that should be applied to large or transient excursions in resource consumption. Those factors may not be accounted for when the cloud management system or associated administrative infrastructure is incapable of detecting such consumption events within a relevant consumption period.
In addition, in cases it may be useful for the cloud user, cloud provider or other administrator or user to detect and monitor the instantaneous resource consumption of a set of machines or networks, for instance, to detect irregular or anomalous conditions or events that occur on a real-time or near real-time basis, for example to initiate workload rollovers or to perform other management actions.
In further aspects, corporations or other entities can operate cloud installations involving comparatively large-scale numbers of users, such as thousands, fens of thousands, or other numbers of users. In those and other scenarios, the set of users may be organized or broken down into a collection of multiple groups or sub-groups, for example to incorporate different engineering teams, management teams, software teams, finance teams, and/or other collections, lists, or partitions of users. In aspects, different groups of users in the overall collection of users may use or share entitlements to the same, overlapping, or partially overlapping set or sets of cloud resources, such as application instances, virtual machines, operating system instances, services such as bandwidth services levels, security services or levels, or other service levels, and/or other cloud-based resources. In conventional cloud platforms, different groups of the collective set of users may or may not be aware of each others' subscription levels or service commitments, and may be administered or managed by different systems administrators or other users, for instance in different locations or possibly different countries. In those and other scenarios, the subscription or consumption periods over which the overall set of entitlements are being tracked and managed may not be visible or be able to be configured from any one access point. Situations may arise therefore where a corporation or other aggregate entity may have its resource consumption metered over time frames or intervals which are too large to detect or identify short-term spikes in consumption on a collective basis, or too small to average out short-range fluctuations in consumption to generate a representative rate of consumption.
It may be desirable to provide systems and methods for generating optimized resource consumption periods for multiple users on a combined basis, in which sets of consumption data and related tracking information can be collected from groups of users, and analyzed to determine modified or optimized resource consumption periods and/or other tracking parameters for the users, on a collective basis.